Draft (untested) install-n.bat - #240
Conversation
…with a + so that triton patch could load.
|
why are we updating to 2.8 again ? I don't usually update unless it is absolutely necessary. Also at the moment 6.2.4 is the latest official hip available for windows. I am not going to force people to install experimental / custom stuff. The rock build is an entirely optional thing and for that I am not even showing it in the main readme as you can see. |
Because 2.7 is fundamentally incompatible with Triton >3.0. Also, it has much better memory management (it almost doesn't leak).
Well, technically the hip DLL in c:\windows\system32 is HIP version 6.4 (courtesy of the latest adrenaline installer). Since I don't know where to get these special sources for 6.4, it was either 6.2 or 6.5. The 6.5 requirement actually came from the original issue opened by alex (was that his name?) in your instructions. |
|
Actually, I think the logic was that because the TheRock version being used was 6.5, we needed to use 6.5 HIP SDK. But that's not necessarily true, as only Triton actually uses the SDK, and it's not linked to a specific version of HIP as far as I know. Further testing will be required. Postnote to my earlier comment: It loads the hipsdk 6.4 dll from windows\system32, and doesn't ever actually load the dll in the AMD\HIP directory. Another postnote: Sorry, I guess that doesn't explain a great deal to a non-programmer. And in truth, I can't really find a way to explain exactly what it does mean, except that it's not like it's loading untested drivers into the kernel or anything nasty like that. |
|
I am not going to update to latest torch unless it is absolutely necessary. So I can do only copying libs folder & patching triton (if that would work with the current setup) . |
|
So the most important thing to know about HIP SDK 6.4 (and above) is that it adds support for gfx1201. My triton patches for triton 3.4 will absolute work with torch 2.7, I just need to add the patches to fix torch 2.7. I'll tweak the install a bit and upload a new PR. But not right now. |
so you are saying just using that dll that comes with latest drivers in the windows folder , it would be hip 6.2.4 , with only one dll 1201 would be supported ? then it is only usable for the newer 9000 series , isn't it ? and can be added to readme / instructions if people using those gpu's want to try. |
|
I'm saying that regardless of whether you install HIP SDK 6.5, the gfx1201 will work, because it will always be using HIP 6.4 DLL from c:\windows\systems. But stuff that is compiled by Triton won't take advantage of any gfx1201 speed-ups or use fp8 latent space, because Triton won't know about them, unless there it has the 6.5 SDK installed. Though how much of a difference that would actually make with pytorch 2.7 installed is another matter. Compilation is something that always improves with updates in pytorch. |
Triton now only installs for 3.11 and 3.12. You should be at least on 3.11 anyway. It is also patched. The "libs" folder needed for triton to work is now automatically copied. Thanks to https://github.com/sfinktah
|
added lib copying and triton install being only for 3.11 and 3.12 also added your patch, trying it now. at least installation works without problems. sage-attention works as usual. torch compile shows lots of errors. you could probably solve them though (it was kinda working with your previous "patch". added triton errors.) |
|
Yeah, you didn't add the patch. And while the patch fixes those errors you pasted, that just opens the door for some wierd CUDA related errors that I have no idea have to solve, and they stop the job executing. |
|
... though now I'm having the same problems with 2.8.0. So I'm just confused. Maybe you should test yourself with 2.7.0 by running this patch inside the venv. |
|
Added your patches, and then added gfx code setting in zluda.py, deleted triton folder (to see it run again) and it works. Here is the startup : And here is a wan 2.1 image generation. Other than the debug and info no errors. Just like the rock version I am using atm. So, doesn't this mean it is working ? EDIT : Tested both zluda and rock versions with the same wan 2.1 wanwrapper 8 step image generation (1024x1536 , 1 frame generation) workflow. (sage-attention is enabled always) zluda version (install-n) rock version So I think torch compile is definately working at least it IS making a difference and it is as good as rock version. /FOR MY RX 6800 at least/ |
|
Yeah, that all looks like it's working. I should note that I start with --use-sage-attention usually, or sometimes --use-flash-attention. Those can cause their own set of errors. Also, I am testing using a Chroma workflow that uses the native comfyui inductor compile node (seems to be faster and more reliable than Kijai's more complex one), and I seem to be having some kind of other issue that is causing the errors to continue even when I update to pytorch 2.8 again. That's why I wanted you to check it. The error that is getting me -- which you might have seen before -- is: I'll do some testing with my wan workflows, that is a good idea. |
|
ack I didn't have the right comfy/customzluda/zluda.py file, so it wasn't doing those Triton checks at startup. No idea how that happened, but checking everything again now to see if pytorch 2.7 will work now. |
|
okay, so that is sorted out. i also have stats. my chroma test render takes
If memory serves, 14 seconds of that difference is in the prompt encoding. I will have to do proper breakdown graphs to be sure, and this "two versions of zluda.py" thing will have be checked -- one probably goes faster than the other. 
|
# Conflicts: # install-n.bat
…mised version. Switched to pytorch 2.8 non-nightly.
…all -r requirements.txt
…all -r requirements.txt
# Conflicts: # install-n.bat
# Conflicts: # install-n.bat
2 participants
Let's just let this set here until we've tried in, and perhaps changed it a bit.